The invention relates to the general field of telecommunications.
It relates more particularly to processing emergency calls in a voice over Internet protocol (IP) multimedia subsystem (IMS) core network as defined by the third group partnership project (3GPP) standard, and in particular it relates to transferring an emergency call initiated from a first access network to a second access network. Thus, the invention applies in preferred but non-limiting manner to transferring an emergency call initiated in a packet switched (PS) mobile access network such as a 4th generation (4G) network or a long-term evolution (LTE) network that relies on an IMS core network architecture, to a circuit switched (CS) access network of the 2nd generation (2G) or the 3rd generation (3G) (for voice communications) such as a global system for mobile communications (GSM) network, a universal mobile telecommunications system (UMTS) network, etc.
In voice-over-IP (VoIP) IMS core networks, there exists a procedure referred to as single radio voice call continuity (SRVCC) that makes it possible, in the event of losing coverage of the 4G access network, to handover (transfer) a call (and in particular an emergency call) from the IMS core network to the conventional 2G/3G CS network.
More precisely, an emergency call initiated by a mobile terminal on an LTE 4G access network is processed by an emergency call session control function (E-CSCF) server. While setting up the emergency call session, the E-CSCF server selects an emergency access transfer function (EATF) node or instance in order to anchor the signaling, i.e. in order to force the signaling concerning the emergency call to pass via that EATF node. The EATF node is thus suitable in particular, where appropriate, for processing requests to transfer the emergency call to an access network other than the 4G access network on which the call was initiated, and in particular to a 2G/3G circuit switched access network, in order to ensure continuity for the emergency call while it is being transferred from a first access network to a second access network. This procedure, and also the functions of the EATF node are described in particular in the following specification documents: 3GPP TS 24.229 entitled “IP multimedia call control protocol based on session initiation protocol (SIP) and session description protocol (SDP); Stage 3”, v13.2.1, June 2015; and 3GPP TS 24.237 entitled “IP multimedia (IM) core network (CN) subsystem IP multimedia subsystem (IMS) service continuity; Stage 3”, v.13.1.0, June 2015.
In the present state of the 3GPP standard, in the event of the mobile terminal losing coverage from the 4G access network on which the emergency call was initiated, a request for transferring the call to the 2G/3G CS network is sent by the 4G access network to the mobile switching center (MSC) device of the 2G/3G network that covers the 2G and/or 3G cells in which the mobile terminal is located. In known manner, the MSC device is in charge of processing calls sent and received over 2G/3G networks (including emergency calls) and of interconnecting 2G/3G networks with other telecommunications networks (including the 4G network on which the emergency call was initiated). The MSC device then transfers the transfer order to the IMS core network, and more particularly to the interrogating-CSCF (I-CSCF) server of the IMS core network, which is the point of entry to the IMS core network, in the form of a session initiation protocol (SIP) INVITE request sent to a predefined emergency call transfer identifier or number also referred to as an emergency session transfer number single radio (E-STN-SR) number. The E-STN-SR number may be configured as a public service identity (PSI) and it may be stored in the home subscriber server (HSS). The I-CSCF server can then interrogate the HSS using the E-STN-SR number to obtain an address of the EATF node in which the signaling of the emergency call that is to be transferred is anchored.
For a given IMS core network, the standard presently provides for a single E-STN-SR number configured on all of the MSC devices that interconnect with the IMS core network, and a single EATF instance associated with that single E-STN-SR number to which the I-CSCF server sends the SIP INVITE request received from the MSC device. As a result, loss of the site hosting the single EATF instance (e.g. for reasons of congestion or loading) leads to the total loss of the emergency call transfer function in the IMS core network, which is particularly damaging.
In order to avoid such a situation, it is possible to envisage deploying a plurality of EATF instances in a single IMS core network. Managing a plurality of EATF instances also makes it easier to authorize configurations in which a plurality of regions or countries are covered by a single IMS core network, but in which dedicated E-CSCF/EATF instances are allocated per region or per country, since the translation of emergency numbers is always specific to the country/region of deployment.
Nevertheless, this situation in which a plurality of EATF instances are deployed in a single IMS core network is not presently envisaged in the standard. Unfortunately, in order to transfer the emergency call successfully, such a situation makes it necessary to ensure that the EATF instance selected by the I-CSCF server coincides with the EATF instance selected by the E-CSF server for anchoring the emergency call session that is to be transferred.
Document WO 2013/075746 proposes a solution for redirecting an emergency call transfer request step by step among a plurality of EATF instances of the IMS core network, making it possible to manage situations in which the EATF instance that receives the transfer request is not the instance in which the call session for transferring is anchored. Nevertheless, it should be observed that that solution does not work when the first EATF instance as selected by the I-CSCF server and to which the transfer request is transferred is itself not accessible, e.g. as a result of failure or congestion of the site hosting that instance. Furthermore, the transfer request following a path among the various EATF instances or being redirected to another EATF instance gives rise to a transfer delay that, under certain circumstances, can lead to the emergency call being cut off if the transfer is not completed quickly.